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Abstract 

This article describes the status of the ALPHA++ project of the ALEPH 
collaboration. The ALEPH data have been converted from Fortran data 
structures (BOS banks) into C"*""*" objects and stored in a object oriented database 
(Objectivity/DB), using tools provided by the RD45 collaboration and the LHC"'"^ 
software project at CERN. A description of the database setup and of a preliminary 
version of an object oriented analysis program is given. 
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1. Introduction 

Object oriented programming is becoming the new 
paradigm for software development in high energy 
physics, in particular in view of the upcoming, 
very demanding LHC project and its experiments. 
In order to provide an analysis platform and 00 
application software, the LHC+"'" project has been 
set up at CERN[y. Furthermore, commercial 
products for the storage of persistent objects in 
so called object databases are being evaluated 
by the RD45 collaboration[Q. The current 
candidate for a large scale application at CERN 
is Objectivitv/DB[|||. In ALEPH a project called 
ALPHA++Q has been set up, with the following 
goals: 

• convert the ALEPH data from a Fortran 
(BOSQ) bank style into persistent objects 
and write them to an object database 
(Objectivity/DB) 

• rewrite a mini-version of the ALEPH analysis 
package ALPHA|^ in an object oriented 
computing language (C++), based on the 
object database 

• compare the standard and 00 performance 
with regard to the efficient access of the data 
and their manipulation 

• test the software engineered by the RD45 and 
LHC"*""*" projects 

• provide input and experience for a possible 
archiving of ALEPH data 

• give an opportunity to learn 00 analysis, 
design and programming. 

In this report we present the structure of the 
ALEPH object database and a preliminary version 
of the analysis program. 



2. The ALEPH data structure and its 
conversion to objects 

ALEPH uses the Fortran based BOS system for 
the memory management. The event data are 
kept in memory in a large array which is globally 
accessible as a common block. The data are 
organised in so called banks, and the data definition 
language (DDL) for these banks is provided by 
ADAMO0. The ADAMO package offers a 
conversion to C header files, which facilitates the 
automatic conversion of the ALEPH DDL to C"'""'" 
classes, or to be more precise, to the ddl-files needed 
for the setup of an Objectivity/DB database. It has 
been decided to perform a one-to-one conversion 
of all the relevant banks stored on an ALEPH 
DST (Data Summary Tape), which can be read by 
the analysis program ALPHA. A simple C"'"'" tool 
has been developed which allows for the automatic 
conversion of the ADAMO DDL of all 173 relevant 
banks into C++ classes. An example of the 
correspondence between the ADAMO description of 
the track bank FRFT and its C++ implementation 
is given in Fig.|l|. 

The general DDL structure as implemented in 
the Objectivity database is outlined in Fig.||. 

A class AlephBank serves as a base class for 
all the ALEPH banks. Persistency is obtained 
by inheritance from the Objectivity class ooObj. 
The class AlephBank stores the name of each 
bank, and defines the interface for the reading 
from and writing to memory of the bank contents. 
Each ALEPH bank is implemented as a class 
NAME_Bank, where NAME is the BOS name of 
the bank, such as FRFT. This class NAME.Bank 
contains the instances of the class NAME. 
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Figure 1. Correspondence between the ADAMO 
description of the track bank FRFT and its C^^ 
implementation 
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Figure 2. The DDL structure of the ALEPH object 
database 
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Figure 3. The database structure of the ALEPH object 
database 



3. The ALEPH object database 

The database structure of the ALEPH object 
database is reproduced in Fig.||. At the basis 
there is a federated database called ALEPHDB, 
which contains several databases. These databases 
either contain real data from different data taking 
periods with or without pre-classification of events, 
or Monte Carlo events from fully simulated hadronic 
Z decays. 

Every database has a container holding Run 



objects. These objects store the run number and 
have bi-directional links to all the event objects of 
the corresponding run and to banks which store 
global run condition data. Furthermore, for every 
run there is a container with the event objects of 
this run and an additional container with all the 
bank objects per run. The event objects store the 
event number and the classification bit of the event, 
and have bi-directional links to all the banks of the 
event. At the moment about eight Gbyte of real 
and Monte Carlo data are stored in the federated 
database. The size of an hadronic Z decay event is 
w lUKB in the old EPIO format and « U5KB 
in the object database. The overhead arises mainly 
from the relationships which are stored in the object 
database. 

4. Analysis Program 

The ALPHA++ analysis program is based on the 
structure of ALPHA. Two basic objects are defined: 
the Tracks and the Vertices. 

A Track can be a charged track reconstructed 
in the TPC, a photon identified in the ECAL 
or a general Energy Flow Object. The common 
attributed of a Track are: the total momentum 
with its components, the energy, the mass and 
the charge. A Track can also have more specific 
attributes depending if it is a charged track, a 
photon or a Energy Flow Object. 

The previously described structure has been 
implemented in ALPHA++ with an abstract class 
AlObject (Fig.^) with the common attributes of a 
Track defined as purely virtual member functions. 
The concrete transient classes Altrack (charged 
tracks), AlEflw (Energy Flow) and AlGamp 
(photons) are defined by inheritance from AlObject 
(Fig.|). 

The same principles apply also in the definition 
of the Vertices (Fig.^). There is an abstract 
class AlVertex with the basic attributes, and 
two concrete transient classes AlMainVertex 
holding the position of the interaction point, and 
AlGenVertex for the secondary vertices found by 
the reconstruction program (Figj6|). 

The implementation of the previously men- 
tioned transient classes in ALPHA++ makes use 
of the ALPHA internal banks QVEC (containing 
the Tracks) and QVRT (containing the Vertices). 
This is done in the following steps: 

• For each event the relevant persistent classes 
from the Objectivity database are read and the 
corresponding BOS banks in the fortran BOS 
common are filled; 
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class AlObject { 

public: 

-AlObjectO; 

virtual float QP() = 0; 

virtual float QX() = 0; 

virtual float QYO = 0; 

virtual float QZO = 0; 

virtual float QE() = 0; 

virtual float QM() = 0; 

virtual float QCH() = 0; 
): 



class AlVertex { 
public: 
-AlVertexO; 

virtual float VXposition() = 0; 
virtual float VYpositionO = 0; 
virtual float VZposition() = 0; 
virtual int Vertex_number() = 0; 
virtual int Vertex_type() = 0; 
virtual float ChiSquareFitO = 0; 
virtual float* CovMatrix() = 0; // 
pointer to covariance matrix 

); 



Figure 4. 
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29 - 10-3 
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Table 1. Preliminary results. The CPU time for 
Hadronic Events (thadr), for all triggered events (tail) 
and the job initialisation time {tinu) are given. The 
CPU time is in Alpha 8400 units, corresponding to 185 
CERN units. 
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Figure 5. The AlObject inheritance structure 
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Figure 6. The AlVertex inheritance structure 



• the fortran subroutines which starting from the 
BOS banks construct the internal QVEC and 
QVRT data structures are called from C"'"'"; 

• the concrete C++ classes (like AlTrack, 
AlMainVertex ...) are instantiated using the 
data contained in QVEC and QVRT; 

• for each event the transient class AlphaBanks 
containing all the instances of the previous 
classes and giving access to them through 
member functions is instantiated. 

The choice to call FORTRAN from C++ in the 
analysis program is due to the fact that there are 
many algorithms in ALPHA which, on a short time 
scale, are not possible to develop in C++. Therefore 
our strategy is to have a FORTRAN "wrapped" 
analysis program already working and to use it as 
a basis to develop new C++ code and algorithms. 



5. Preliminary performances studies 

In order to check the performances of the 
Objectivity/DB a very simple analysis program 
has been set up both in ALPHA and ALPHA++. 
This program applies some cuts to hadronic Z 
decays events to preselect good events for the QCD 
analyses. In addition some histograms are filled. 
The preliminary results are shown in Table |l|. We 
found that the analysis CPU time is negligible 
as well as the histogram filling time. The factor 
« 2 difference in CPU time per event between 
ALPHA++ and ALPHA is due to the input/output 
operations performed by the Objectivity/DB. 

6. Conclusions 

A project called ALPHA++ has been set up with 
the ALEPH experiment in order to test new object 
oriented approaches to data storage and analysis. 
The DDL structure of the object database and a 
preliminary version of an 00 analysis program have 
been presented. Future work will concentrate on the 
further development of the analysis program as well 
as on detailed performances studies. 

References 



[1] 

[2] 
[3] 
[4] 
[5] 
[6] 



[7] 



ittp://w 



rn.ch/aad/lhc + + y'indcx.ht]t 
rn.chy asd/lrddb / indcx.html 



iUp://w 


ww.oDjectiviny. com/i 








ittp://al 


Icphwww.cern.ch's.disscrto/objty/ Welcome, html 








ittp://w 


ww.ccrn.ch/Light/cxamplcs/alcph/bos/bos.htm 








ittp://a 


cphwww.ccrn.ch/ALEPHGENERAL/phy/doc/a 


Igu 


idc/alguidc.html 


ittp://-w 


wwl.cern.ch:80/Adamo/rcfmanual/Documcnt.lit 







AlVertex 



TYPEO 

QVX() 

QVY() 

QVZ() 

KVN() 

KVTYPEO 

QVCHIFQ 

QVEMO 



QvrtBase 



-O- 
^ 1 











AIMainVertex 




AIGenVertex 








0. 





AlObject 

QX() 

QY() 

QZ() 

QE() 

QM() 

QCHQ 

TYPEQ 



QvecBase 



AlEflw 


0..1 


AITrack 







AIGamp 



AlphaBanks 
AlphaBanksO 
~AlphaBanks() 
EflwO 
GampecO 
MainVertexO 
GenVertex() 
NTrackO 
NEflwO 
NGampecO 
NGen_Vertex() 
TrackO 




